I am not sure high_resolution_timer is the appropriate choice -- it is implementation defined which clock is used for the underlying high_resolution_clock. https://en.cppreference.com/w/cpp/chrono/high_resolution_clock.html suggests that libstdc++ vs libc++ may even select different ones. (the most problematic result of this may be that when compiled with libstdc++ this timer is non-monotonic, where with libc++ it is monotonic)

The most consistent choice would probably be to use system_timer (i.e. system_clock).

Related #1830

I am not sure high_resolution_timer is the appropriate choice -- it is implementation defined which clock is used for the

In tests I have seen the deadline_timer fire seconds late. I was interested in using a higher resolution clock to see if that would help this problem.

It's the ambiguous inconsistency that is my concern. I just tried

#include <chrono>
#include <iostream>

int main() {
    using namespace std::chrono;

    std::cout << "Period: " << high_resolution_clock::period::num << "/" << high_resolution_clock::period::den << " seconds\n";
    std::cout << "Is steady: " << high_resolution_clock::is_steady << "\n";
    return 0;
}

and sure enough the output is different on libstdc++ vs libc++ (clang 21). The code should be explicit about what kind of clock it is getting to avoid any surprises or inconsistencies (now or in the future).

Since deadline_timer is wall clock based, system_timer seems like the appropriate replacement. And system_timer is what is being used by libstdc++ anyways for high_resolution_timer so it's not like there is any extra magic that high_resolution_timer gives.